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1 Introduction 



The GigaPoint bus is the data transport medium between the GigaPoint Routing CrossConnect ASIC (GRX) and a 
number of GigaPoint Access Processor ASICs (GAPs). The GRX is the switching core on the Routing and 
Arbitration Processor (RAP) assembly. The GAP ASIC is the GigaPoint interface at each C7 line unit. A GAP 
ASIC is also present on the RAP at the PHY interface. 

The GigaPoint is a high-speed point-to-point serial bus design based on the Gigabit Ethernet SerDes. Each 
GigaPoint consists of two differential data pairs; transmit and receive, a 16384MHz clock and timing reference 
frame and clock signals. Both GAP and GRX interface to the GigaPoint through a SerDes. 

The GigaPoint bus performs the following functions: 

• Data transport at a fixed line rate of 3 . 1 1 04Gbps 

• Support for two different traffic types (STM and packet) over one medium 

• Transport of framing synchronization signal (6ms superframe) 

• Transport of additional packet-related control and routing information within the GigaPoint header 
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2 Reference 



2.1 Definitions 

The following definition are used within this document: 



2.1.1 Glossary of Terms 

Async channel 

Downstream 
GP Channel 
Packet 
Sync channel 

TDM packet 
Upstream 



A GP Channel that carries packets that have no synchronous fixed position with 
respect to GigaPoint frame or superframe 

GigaPoint traffic from the GRX to the GAP ASICs. 

One of sixty byte-interleaved data channels on the GigaPoint bus 

A GigaPoint data unit that carries unicast packet data 

A GP Channel that carries packets that have synchronous fixed position with 
respect to GigaPoint frame or superframe 

A synchronous GigaPoint packet that carries DSO TDM data. 

GigaPoint traffic from the GAP ASIC to the GRX. 



2 ,1 .2 Abbreviations 





AAL-1 


ATM Adaptation Layer Type 1: AAL functions in support of constant bit rate ? time- 
dependent traffic such as voice and video. 




BIP 


Bit-Interleaved Parity 




CRC 


Cyclic Redundancy Check 




CSI 


Convergence Sub-layer Indicator 




DCC 


Data Communications Channel. 




DSO 


Digital Signal level 0 - 64kbps 




DS1 


Digital Signal level 1 - 1.544Mbps data format 




EOW 


Engineering Order Wire 




FLP 


Fixed-length packet - All packets over the GigaPoint are FLPs. 




GAP 


GigaPoint Access Processor - Calix ASIC, line unit GigaPoint interface 




GRX 


GigaPoint Routing CrossConnect - Calix ASIC, switching fabric 




HEC 


Header Error Check 




IP 


Internet Protocol 




LOS 


Loss of signal 


"S..S 


MAC 


Media Access Control 


iE 


OH 


Overhead timeslot 




PDU 


Protocol Data Unit 


m 


PHY 


Physical layer 




PLL 


Phase Locked Loop 




POH 


Path overhead 


5 ■■ ■ H 


POTS 


Plain Old Telephone Service 


= 


PPP 


Point-to-Point Protocol 




PRBS 


Psuedo-Random Bit Sequence 




RAP 


Routing and Arbitration Processor 




SAR 


Segmentation and Reassembly 




SerDes 


Gigabit Ethernet Serializer-Deserializer 




SONET 


Synchronous Optical Network 




SPE 


SONET Payload Envelope 




STS 


SONET traffic stream 




TDM 


Time Division Multiplexing 




TSI 


Time Slot Interchanger 




VOQ 


Virtual Output Queuing 
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3 Feature Description 
3.1 Backplane Interface 



The GigaPoint bus is primarily a high-speed point-to-point interface between line unit slots and redundant RAP 
common control assemblies, as shown in Figure 1 below. 



RAP a 



RAP b 







GRX 

























Line Unit 0 



GAP 



GigaPoint 




to line unit 1-n 



GigaPoint 



to line unit 1-n 



Figure 1 - GigaPoint High Speed Data Path 

Additional clocks and frame sync signals are bused across multiple slots. 



3.2 GigaPoint Signals 

The fall complement of GigaPoint backplane interface signals is described in Table 1 below. 



Signal 


Bused 


Description 


TXP 
TXN 


No 


Transmit differential data pair. Transmit data is driven by the 

line Unli SlOtS tOWdXU. UlC ivrtJr a&aciiiuiy . 


RXP 
RXN 


No 


Receive differential data pair. Receive data is driven by the RAP 
toward line units. 


SONET_19M_CLKP 
SONET 19MCLKN 


Yes 


PECL differential 19.44MHz SONET system clock distributed 

|_ . . "DAT) itmi+ c!r\fo Tyx//"* nlr^nV -nnirc arp TyiicpH "frmTl 
Dy tne K-nJr XO line UUll SiOtS. I WO t/lUUK. pdlib die uuacu iium 

each RAP; one to the west line unit slots and one to the east. 
These clocks are a reference for SONET optical line units. 


CODEC_16M_CLK 


Yes 


Single-ended 16.384MHz CODEC system clock distributed by 
the RAP to line unit slots. Two clock pairs are bused from each 

Jx/vr, One tO me West line UIlll blUlo aiiu uiic tu mc cast, meat 

clocks are the CODEC reference clock for POTS and Combo line 
units. 


T1_12M_CLK 


Yes 


Single-ended 12.352MHz Tl system clock distributed by the 

X> A "D -fi-i K«o n-ni-f- olr*tc TiTtm r^lnplr nsnr<! arp VvhqpH from ftacVl 
JVf\Jr tO llllC tlllll olUlo. 1 WU V/lUviv pallo HL\, uuatu xiwin vavn 

RAP; one to the west line unit slots and one to the east. These 
clocks are the Tl framer reference clock for T1/DS1 line units. 


CLKREFA 


Yes 


Reference clock. Reference frequency may be 1.544MHz ? 
2.048MHz or 16.384MHz. Line units are provisioned to drive 
these redundant backplane nets. They are bused across all line 
unit slots within a shelf. The RAP's timing core may select one 
of these signals as a reference clock. 


SYNCREFA 
SYNCREFB 


Yes 


Reference frame sync. Frame sync interval is 6ms. Line units 
are provisioned to drive these redundant backplane nets. They 
are bused across all line unit slots within a shelf. The RAP's 
timing core may select one of these signals as a frame reference. 


DS0_SYNC 


Yes 


DSO frame sync distributed by the RAP to line units. An 8kHz 
frame sync signal from each RAP drives all line unit slots, both 
west and east. DSO sync is an independent framing reference use 
by 64kbit Digital Data Service (DDS) line units. 



Table 1 - GigaPoint Signals 
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3.3 The SerDes Function 



The SerDes performs the parallel-to-serial and serial-to-parallel data conversion and clock extraction for the 
GigaPoint bus. The SerDes is based on extensions to the Gigabit Ethernet Media Independent Interface 
specifications of IEEE 802.3z. The serial transceiver interface operates at a line rate of 3.1 104Gbps. 

3.3,1 SerDes Crosstalk 

The SerDes transmit interface must not drive an unterminated backplane GigaPoint. SerDes transmitters without 
destination terminations are strong sources of GigaPoint crosstalk. Line units must never drive a GigaPoint to RAP 
slot without a RAP card present. RAP cards must never drive a GigaPoint to a line unit slot without a line unit card 
present. Potential solutions to this problem include backplane interlocks and circuits that disable the SerDes 
transmitter when the receiver is in a LOS condition. 

3.4 Data Capacity 

The GigaPoint operates at a serial bit rate of 3.1104Gbps. At this rate, the GigaPoint has a data capacity of exactly 
25% greater than STS-48, or the equivalent of STS-60. 

Over a 125us SONET frame, sixty byte-interleaved GigaPoint channels (GP Channels) are designated Each GP 
Channel transports 810 bytes every 125us frame. 

These sixty GP Channels are independently configurable for STS, synchronous packet or asynchronous packet 
transport and are defined as STS channels, Sync channels or Async channel respectively. 

GigaPoint overhead consumes five bytes of bandwidth each 125us frame. Overhead timeslots are transported within 
the first dedicated packet GigaPoint channel, the overhead channel. As with the other fifty-nine channels, the 
overhead channel can be provisioned as an STS, Sync or Async channel. 
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3.5 GigaPoint Traffic Types 

The GigaPoint interface transports five traffic type in fixed priority. They are: 



Priority 


Transport Type 


Channel Type 


Traffic Type 


1 


Channelized 


Any 


GigaPoint Overhead 


2 


Channelized 


STS 


STS channels 


3 


Sync packet 


Sync 


TDM packets 


4 


Sync packet 


Sync 


Multicast, SAR .... 


5 


Async packet 


Async 


Unicast packets 



Figure 2 - Traffic Priority 



3.5.1 GigaPoint Channel Maps 

GigaPoint transmit and receive interfaces each have an independent channel map. The GigaPoint channel map and 
common frame and superframe sync information are used by transmit and receive logic to identify the sync and 
async packet slots and STS channels in the GigaPoint stream. The channel map at a receiver must match the 
corresponding "far end" transmitter map. However, upstream and downstream channel maps for the same 
GigaPoint port may be asymmetrical. 

3.5.2 GigaPoint Scrambling 

The GigaPoint Bus requires a data scrambling function that will guarantee a 1:70 transition density. This transition 
density is required to ensure that the receive PLL within each SerDes receiver can maintain a lock to the incoming 
data stream. Two scrambling functions are provided; a GR-253-compliant SONET scrambler and a payload 
scrambler. Software may enable or disable each scrambler independently. In normal operation, one and only one 
scrambler must be enabled. 

The SONET scrambler is implemented as a failsafe in the event that the payload scrambler does not meet "real 
world" SerDes transition density requirements. 

The payload scrambler is potentially more immune to an OC-48c "killer pattern" due to its software-configurable 
seed and 48-frame run length. 

3.5.2.1 SONET Scrambling 

GigaPoint data is scrambled based on the SONET scrambling format as defined in GR-253-CORE. All data 
excluding the A 1 and A2 framing bytes in the overhead channel, is scrambled at the GigaPoint transmit MAC and 
de-scrambled at the corresponding GigaPoint receive MAC. 

3.5.2.2 Payload Scrambling 

The GigaPoint payload scrambler is implemented in a manner similar to that of the SONET scrambler. A 
polynomial is generated from a preset state on a superframe interval. The resulting scrambler mask words are 
XORed with GigaPoint data at the scrambler and descrambler blocks. The payload scrambler differ from the 
SONET scrambler in the following ways: 

• The payload scrambler polynomial is generated on the 6ms superframe rather than the 125us frame 

• The payload scrambler polynomial is different 

• The preset word at superframe sync is configurable from software 



At superframe sync, the 48-bit seed word from the Payload Scrambler Seed register is loaded into the scrambler 
register. On each following 77.76MHz clocks, the scrambler register contents are fed back to the input through a 
40-bit offset XOR equation that provides the next 40-bit value in the polynomial. 

The resulting 40-bit word is XORed with the receive GigaPoint data immediately after the overhead extract stage of 
the descr_oh block. The descrambled GigaPoint receive payload/overhead is driven to the receive frame align 
FIFO. 

3.5.3 GigaPoint Channels 

Each 125us GigaPoint frame is divided into sixty GigaPoint channels. The sequence of sixty octets, one per 
GigaPoint channel, is repeated 810 times per frame. A total of 48,600 bytes are transferred each 125us frame. 
GigaPoint channels conform to the interleave format shown in Figure 3. 



j Start of 1 25us GigaPoint frame 




Figure 3 - GigaPoint Channels 

3.5.3.1 Overhead Channel 



The first GigaPoint channel carries dedicated overhead bytes. These overhead bytes are positioned in SONET 
transport overhead (TOH) timeslots. The overhead bytes carry framing, control and status information between the 
GRX and GAP. As with any other channel, the overhead channel may be provisioned as an STS, sync or async 
channel. Because overhead bytes are sent in SONET TOH timeslots, STS payload may be transported in the 
overhead channel, however the STS TOH will be overwritten with overhead bytes. 

3.5.3.2 STS Channels 

The GigaPoint interface supports transport of up to 60 STS-1 channels. Each channel is assigned 810 timeslots 
within a 125us GigaPoint frame. These timeslots are fixed in position relative to the GigaPoint frame. Channels are 
configurable on a per STS-1 basis at the line unit and RAP. When STS channels are not allocated for STS-1 
transport, they revert to packet traffic. When STS-1 traffic occupies the maximum of 48 channels, twelve remaining 
channels transport overhead and packet traffic. 

STS payload may be transported locked or floating. In locked or floating mode, the line unit's STS interface aligns 
the SONET transport overhead to the GigaPoint frame. 

Locked payload STS traffic aligns both the SONET TOH and SPE to the GigaPoint frame. A fixed value in the 
TOH HI, H2 and H3 payload pointers of '00' positions the path overhead directly after the transport overhead on 
every frame. An example of a locked STS channel is the overhead channel, as shown in Figure 8. 

Floating traffic is transported GigaPoint-aligned SONET transport overhead and floating SPE (path overhead and 
payload). As with standard SONET interfaces, the frame position of the SPE is determined by the offset value of 
payload pointers HI, H2 and H3. 
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3.5.33 Synchronous Channels 

Synchronous packets are 64-byte packets that are transported over the GigaPoint in synchronous GP channels. 
Synchronous packets are in fixed position relative to GigaPoint frame sync. TDM and multicast FLPs are 
synchronous packets. 

Each TDM FLP assignment dictates the frame position of one packet per frame. In order to enable TDM FLP 
merging, TDM FLPs assigned to the same TDM packet slot arrive at the GRX GigaPoint simultaneously. TDM 
FLPs are switched through the GRX's synchronous crosspoint 

Multicast packets are assigned from remaining synchronous packet slots as a means to allocate specific multicast 
bandwidth. While synchronous packet slots assigned to multicast are fixed in position to the GigaPoint frame, a 
specific packet slot may carry multicast packets of different flows on subsequent frames. Switching through the 
GRX's synchronous cross-point simplifies alignment of multiple output GigaPoint interfaces. 

3.5.3.3.1 Synchronous Channel "No-Fly" Zone 



The number of synchronous packets within a 125us frame varies based on channel map. Sync packet slots begin on 
the first available byte after frame sync. As a result, in many channel map configurations there is a region at the end 
of the frame, less than 64-bytes in length, that is not used for sync packet transport. This region is called the 
Synchronous No-Fly Zone (SNFZ). 

Three factors contribute to the size of the SNFZ. They are: 

• Factor A: number of synchronous channels allocated 

• Factor B: channel type of the overhead channel 

• Factor C: synchronous byte shift introduced by the SXC module 

The relationship between Factor A and SNFZ is simple. For every synchronous channel allocated, 810 bytes are 
available to carry synchronous packet traffic. This translates to 12 full packets plus a remainder of 42 bytes. 

Factor B adds one complication to the equation: if channel 0 is configured as synchronous channel, only 805 bytes 
are available for synchronous packet traffic during channel 0 (5 overhead bytes are subtracted from the total byte 
count). 

Factor C accounts for the constant (20-byte) synchronous byte shift between the ingress (or upstream) frame and the 
corresponding egress (or downstream) frame. As the result of the shift, the first synchronous byte in a downstream 
frame is always the 21 st byte after the frame sync. The effect of the byte shift on the SNFZ can be illustrated in the 
following figures: 

Figure 4 shows the scenario where the SNFZ calculated using Factors A and B is greater than 20-byte. In this case, 
the byte shift does not cause the last packet in the downstream frame overflows into the next frame. 
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(D 20-byte shift 
(3) Sync No-Fly Zone 

Figure 4 - Sync No-Fly Zone with < 20 Byte Shift 

Figure 5 illustrates the case where the SNFZ calculated is less than 20-byte. In this case, if the last packet were to be 
scheduled, it would've caused the packet to cross the downstream frame boundary. The solution here is simply not 
to schedule the last packet and thus increase the SNFZ by a full packet. 





Q) STS pipeline delay 

(2) 20-byte shift 

(3) Sync No-Fly Zone 

Figure 5 - Sync No-Fly Zone with > 20 Byte Shift 



In summary, the equations for calculating the SNFZ are: 

Numjjf_Sync_Pkts = (Num_of_Sync_Chs *810-X)/64 

SyncJfoJFfy = (Num_pf_Sync_Chs *810-JQ- (Numj)f_SyncJ>fos * 64) 

iffSyncJfoJFfy < 20) then 

Num_ofJSync_Pkts = Num_of_Sync_Pkts - 1 

SyncJfo_Ffy = Sync_NoJFly + 64 

end if 

(X=0 if channel 0 is not configured as synchronous channel 
X = 5 if channel 0 is configured as synchronous channel) 

3.5.33.2 Opportunistic Use of Synchronous Channels 

Synchronous packet slots not occupied by TDM or multicast packets are available for asynchronous unicast packets. 
The first octet of the synchronous packet slot always carries the synchronous packet type field. The packet type 
value is 4 0(T indicates an idle synchronous packet. This single octet, along with the current state of asynchronous 
transport, allows GigaPoint receive logic to differentiate between synchronous and asynchronous octets. The 
remaining 63 octets are available for transport of asynchronous traffic. 
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Unlike synchronous packets, async packets need not start on synchronous packet slot intervals. An async packet 
started in an asynchronous packet slot may continue through synchronous packet slots. Asynchronous packets may 
start in idle synchronous octets. This opportunistic use of free synchronous packet slots is detailed in Figure 6. 
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Figure 6 - Async Traffic In Sync Packet Slots 

Figure 5 illustrates simultaneous transport of synchronous and asynchronous traffic. The synchronous channels 
transport a multicast packet followed by idle and TDM packets. After the multicast packet completes at octet 64 (1- 
64), the idle packet type field is sent, marking the remaining 63 octets as available for asynchronous traffic. The 
current asynchronous packet completes in a "free" synchronous timeslot and another asynchronous packet begins. 
Asynchronous traffic continues to make use of the idle synchronous packet slot. The next synchronous packet slot 
carries a TDM packet. During the TDM packet transport (when sync packets are present), asynchronous traffic is 
transported exclusively in asynchronous GigaPoint channels. 



3,5.3.4 Asynchronous Channels 

Unicast packet traffic, async packets, are transported in fixed packet slots, but is not aligned to each 125us frame 
sync. Async packets are aligned to 6ms superframe sync. Unicast async packets are transported in Async GP 
Channels and may also occupy timeslots within Sync GP Channels when sync packets are not present. Unicast 
traffic is transported through the GRX's packet cross-point. Unicast traffic carries the lowest priority through the 
GRX. 



3.5.3.4.1 Asynchronous Channel "No-Fly" Zone 

As with sync packet slots, async packets also have a No-Fly Zone. The Async No-Fly Zone occupies the end of the 
6ms superframe. The Async No-Fly Zone is calculated based on the number of channels configured for async 
traffic. The async no-fly zone does not account for opportunistic use on idle sync packet slots. The async no-fly 
zone never exceeds 64 async bytes in duration. 
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3.5,3.5 Channel Priority 

GigaPoint traffic is transported in the following priority: 

1 . GigaPoint overhead 

2. STS channels 

3. Synchronous packets 

4. Asynchronous packets 



Start of 1 25us GigaPoint frame 
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Figure 7 -Traffic In GigaPoint Channels 

As detailed in Figure 7, overhead timeslots in the overhead carry the highest priority. Overhead timeslots are fixed 
in position in hardware. The remaining bandwidth in the overhead channel may be provisioned for use by STS, 
synchronous or asynchronous traffic. 

STS channels are provisioned by software, but once provisioned, these timeslots may not be used for transport of 
any traffic other than STS. 

Synchronous packets are transported in timeslots assigned to fixed positions within the GigaPoint frame. 
Synchronous and Asynchronous packets may be byte interleaved as illustrated in Figure 7. 

Asynchronous packets are transported primarily over asynchronous channels. Asynchronous packets may use 
synchronous channel timeslots when synchronous traffic is not present. Asynchronous packets have no fixed start 
and stop position relative to the GigaPoint frame. However, the first octet of an asynchronous packet always 
occupies the first available asynchronous timeslot subsequent to the 6ms GigaPoint superframe. The first available 
asynchronous timeslot may be a timeslot provisioned for asynchronous traffic, or an available timeslot in an idle 
synchronous packet slot. While sync and async packets have different packet type values, they are delineated by the 
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GigaPoint receiver logic by their relative positions to frame and superframe sync and a GigaPoint channel map 
configuration which must match at GigaPoint source and destination. 
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3.5.4 Packet Traffic 



The GigaPoint interface transports packet traffic in remaining timeslots not utilized by overhead bytes and active 
STS channels. Packet traffic is transported in 64-byte fixed-length packets (FLPs). GigaPoint FLP length is 
optimized for ATM cell transport. GigaPoint FLPs include a 16-byte GigaPoint header (including the ATM cell 
header) and 48 bytes of payload. 

Asynchronous packet types include: 

• Idle Packets 

• Unicast packets 

• HOT packets 

• TOH Packets 
Synchronous packet types include; 

• Idle Packets 

• Host Packets 

• TOH Packets 

• Multicast Packets 

• TDM Strict Schedule Packets 

• TDM Loose Schedule Packets 

GigaPoint FLPs are in fixed positions, or packet slots, relative to the GigaPoint frame and number of active STS 
channels. The utilization of active STS channels determines the maximum packet capacity. Table 2 displays packet 
capacity per GigaPoint frame. 



Active STS channels GigaPoint FLPs per frame Packet Data Rate 

(payload only) 


0 


758 packets 


2.3Gbps 


3 


720 packets 


2.2Gbps 


12 


607 packets 


1.8Gbps 


24 


455 packets 


1.4Gbps 


48 


151 packets 


0.4Gbps 



Table 2 - Packet Capacity 



3.5.4.1 Idle Packets 

Idle packets carry no data payload. They are transported over the GigaPoint solely to transport packet arrival and 
packet grant information between the GRX and the GAP ASIC. The idle packet type applies to both synchronous 
and asynchronous packets. 

3.5.4.2 Unicast Packets 

Asynchronous unicast packets carry data other than TDM as point-to-point flows through the GRX's asynchronous 
crosspoint Unicast packets are transported over asynchronous GigaPoint channels and "idle" timeslots in 
synchronous channels. 
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3.5*4.3 HOT Packets 



Asynchronous HOT packets are similar to async unicast packets with one exception. They do not make use of the 
async packet arrival/grant mechanism. HOT packets are launch from the source line unit through the GRX to the 
destination line unit at the highest async packet priority. 

3.5.4.4 Host Packets 

Host packets may be transported as synchronous or asynchronous packets. Host packets transfer C7 processor-to- 
processor data through dedicated virtual circuits or SONET DCC channels. Host packets are transported over 
+asynchronous GigaPoint channels and "free" timeslots in synchronous channels. 

3.5.4.5 TOH Packets 

Synchronous/asynchronous TOH packets carry portions of the SONET transport overhead between SONET 
interface line units within the C7 system. The TOH packets carry both SONET Engineering Order Wire (EOW) 
PCM samples and SONET Data Communications Channel (DCC) data. TOH packets are transported over 
synchronous/asynchronous GigaPoint channels and "free" timeslots in synchronous channels. 



3.5.4.6 Multicast Packets 

Synchronous multicast packets transport data from one GigaPoint interface to many GigaPoints. Multicast packets 
are transported through the GRX ASIC's synchronous crosspoint 

3.5.4.7 TDM Packets 

Synchronous TDM packets are transported over synchronous GigaPoint channels. They are assigned to specific 
timeslots by the ingress line units. Synchronous TDM packets may be merged and/or multicast. At an egress 
optical interface, these packets are stored in a high priority CoS queue. TDM packets may be loosely or strictly 
scheduled. 

3.5.4.7.1 Strict Schedule 

TDM packets that are strictly scheduled are transported in the specific synchronous packet slot defined by the 
sequence number in their GigaPoint header's VCI field. The sequence number is also used by the line unit's TSI as 
an internal routing tag. Strictly scheduled packets may be merged in the GRX's synchronous crossconnect 

3.5.4.7.2 Loose Schedule 

Loosely scheduled TDM packets are transported over the GigaPoint in the next synchronous packet slot that is not 
reserved for strictly scheduled TDM packets. While the VCI field is not used to position the loosely scheduled 
packet, it is still used by the line unit's TSI as an internal routing tag. 
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3.5.5 Overhead Traffic 



GigaPoint overhead traffic is transported in the overhead channel, GigaPoint channel 0. Five bytes of overhead 
traffic are transported over the GigaPoint every 125us frame. While these bytes occupy locations similar to SONET 
transport overhead bytes, they are not SONET bytes. The byte positions within the frame are intended to allow 
transport of SONET STS-1 frames over GigaPoint 0 without interference with SONET overhead that is not 
regenerated at the line unit egress. The remaining 805 bytes of GigaPoint channel 0 are available for STS, sync 
packet or async packet traffic. GigaPoint overhead byte position in the frame is defined in Figure 8 below. This 
figure represents a single GigaPoint channel. Sixty GigaPoint channel are byte, or octet interleaved foT a total of 
810 bytes X 60 channels, or 48,600 bytes per 125us frame. 
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Overhead: 5 bytes 
Payload: 805 bytes 

Figure 8 - Overhead Byte Position 

GigaPoint overhead bytes correspond in position to SONET section and line overhead. 



Overhead byte 


Position in 
OH channel 


Description 


GA1/GA2 


bytes 1 and 2 


GA1 and GA2 bytes carry GigaPoint framing 


GB1 


byte 91 


BIP-8 parity. Calculated on the contents of the previous 
frame 


GK1 


byte 362 


GigaPoint reset and frame count 


GS1 


byte 721 


GigaPoint active, protect, STS page, user field 



Table 3 - Overhead Byte Definitions 

Overhead data includes 125us framing (GA1/GA2), frame integrity (GB1), and GigaPoint status/control 
(GK1/GS1). The frame integrity byte ensures that the previous 125us frame of data within the overhead channel 
was transported without a bit-interleaved parity (BIP-8) error. 

The GK1 timeslot transports reset and frame count. GK1 bits are defined in section 3.5.5.1. 

The GS1 transports active/protect state of the RAP to the line units. The GigaPoint channel map page select is 
transported both to and from the line units. An additional 5-bit user field is register accessible to software in both 
directions. 
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3,5.5.1 GK1 Downstream Bit Definitions 



jKi carries co 
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B i t 7 Reset bit. The reset bit is driven from the RAP to the line unit on a per-uigar-oini oasis. i ne iwr 

software sets a reset register in the GRX's TX GigaPoint MAC. The MAC transports the reset to 
the GAP'S RX GigaPoint MAC. The RX GigaPoint MAC filters the reset for one superframe. 
Once the reset signal is determined to be valid, the GAP RX MAC drives a hard reset to the 
GAP'S on-chip host processor. 

Bit 5-0 Frame count bits. The GRX TX MAC drives this 6-bit field. It identifies the current 125us frame, 

from 0 to 63, within the 6ms superframe. 

3,5.5.2 GS1 Downstream/Upstream Bit Definitions 
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Bit 7 



Bit 6 



Bit5 



0 = RAP is not active. 

1 = RAP is active. 

Protect bit. With the protect bit, indicates the protection state of this RAP to the line units. 

0 = RAP is not protect. 

1 = RAP is protect. 

GigaPoint channel map select bit. STS/TDM GP channel configuration information is stored in 
active and standby STS map pages, page 0 and page 1. The STS/TDM map select bit identifies 
which of these two pages is active. A change in the STS configuration bit causes a switch in 
active STS map page on the next frame, or superframe boundary. A change in the state of the STS 
configuration bit causes an interrupt to the local processor. 



In the downstream path, this bit controls the STS map in the GAP ASIC's GP Sync controller. 
The Telecom controller drives the bit to the GP MAC at the upstream interface back to the GRX. 

0 - Use STS map page 0. 

1 =Use STS map page 1. 

Bit 4 Extract bit. This bit indicates to the remote MAC that the local card is being extracted. 

0 = Normal operation 

1 = Card is being extracted 

Bit 3-0 User data bits. This bit field allows RAP and line unit software a low data rate communication 

interface. These bits are mapped to transmit and receive registers at the RAP and line unit. 
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3,5.6 GigaPoint Header 

Each packet slot within a frame is made up of a 16-byte GigaPoint header (including ATM header) and a 48-byte 
payload. The GigaPoint header includes the following components: 

• Packet type field 

• Packet class of service field 

• Packet length field 

• Extension field for context bits 

• Backpressure state bits 

• Upstream packet arrival / Downstream packet grant field 

• Facility identifier bits 

• Plane identifier bits 

• Routing map field 

• Flow identifier field 

• Header (WI,VCI,PTI,CLP) 

• Header error check byte 

GigaPoint headers are generated for each packet slot. A header error check byte is transported within each header, 
generated from the previous 120 header bits. The GigaPoint header is illustrated in 32-bit format in Figure 9. 
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Figure 9 - GigaPoint Header Bit Positions 
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3.5.6.1 .1 GigaPoint Header Bit Definitions 



WordO 

Bits 31-28 
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Bits 27-24 



Packet Type field. The packet type field identifies data within a packet slot for routing within the 
GRX and GAP ASICs. The packet type is encoded as follows: 
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Host SOM - Start of message 
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Host COM - Continuation of message 
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Host EOM - End of message 
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Host SSM - Single segment message 
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TOH - Transport Overhead 
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Multicast 
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TDM strict schedule 
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1 


1 


TDM loose schedule 



Packet class of service field. Identifies up to 16 levels of class of service for the current packet. 
Refer to 3.5.6.2 for details. 



Bits 23-18 Packet length field. Identifies the length of valid payload within the current packet. SAR EOM 
and SAR SSM packets make use of this field to identify the end of multi-packet PDUs. A length 
of '0' in a SAR SOM or COM packet indicates packet abort. 

Bits 17-15 Context extension bits. These bit locations are reserved for future context information. 

Bit 14 Async loopback bit. The async loopback bit is only present in async packet headers. Async 

loopback is driven by the GRX arbiter into downstream async packets. At the GAP ASIC it is 
looped to upstream async packet headers and received by the GRX arbiter. Async loopback is 
intended as a means of measuring the async packet transport latency over the GigaPoint. Because 
the latency is dependant on GigaPoint channel configuration, this function allows a real-time 
measurement. 



Bit 13 



Bit 12 



BP bit. The backpressure bit identifies a congested state at the remote GigaPoint' s receive 
interface. At the GRX, an active BP bit indicates a full, or near full queue condition at the 
downstream line unit. At the line unit, an active BP bit indicates a full, or near full condition at 
the GRX's upstream receive queue. 

0 = No congestion 

1 = Congestion, backpressure active. 

Grant BP bit. Upstream GigaPoint only. The grant backpressure bit identifies a congested state at 
the GAP's packet grant FIFO. 

0 = grants enabled 

1 = GAP grant FIFO full, grants disabled 
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Upstream Bits 11-0 

Packet Arrival field. The packet arrival field reports the arrival of packets at the line unit to the GRX's 
VOQ image function within the GigaPoint arbiter. The packet arrival word appears at the GRX receive and 
GAP transmit interfaces. The packet arrival field includes valid, class of service, message type and VOQ 
identifier information as follows: 
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Valid packet arrival bit. 

0 = No packet arrival 

1 = Valid packet arrival 

Arrival class of service bits. These bit define the class of service of the packet 
arriving at the line unit's VOQ. Refer to 3.5.6.2 for details. 

Arrival type bits. The type bits transport arrival state as described below: 



Typel 


TypeO 
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0 


Normal packet arrival. The VOQ 
identifier indicates which queue has 
received a packet. 


0 


1 


Initiate VOQ Audit 


1 


0 


Flush. The VOQ identifier indicates 
which VOQ count should be cleared. 


1 


1 


Terminate Grant Audit 



VOQ identifier bits. When the valid bit is active, this field indicates in which 
VOQ, based on output port, the arriving packet will be stored at the line unit. 
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Downstream Bits 11-0 . 

Packet Grant field. The packet grant field is sourced by the GRX's GigaPoint arbiter. It identifies which 
packet should be driven over the upstream GigaPoint to the GRX based on the grant VOQ ID. The packet 
grant word appears at the GRX transmit and GAP receive interfaces. Because the GAP ASIC at the line 
unit caches grants, the next upstream packet may not be the last packet granted. 



11 


10 


9 


8 


7 


6 


5 


4 


3 


2 


1 


0 


VALID 


COS3 


COS2 


COS1 


coso 


TYPE1 


TYPEO 


VOQ4 


VOQ3 


VOQ2 


VOQ1 


VOQ0 



VALID Valid packet grant bit. 

0 = No packet grant 

1 = Valid packet grant 

COS3-0 Grant class of service bits. These bit define the class of service of the packet 

arriving at the line unit's VOQ. Refer to 3.5.6.2 for details. 

TYPE 1 -0 Grant type bits. The type bits transport grant state as described below: 



Typel 


TypeO 
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Normal packet grant. The VOQ identifier 
indicates which queue is granted. 
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Terminate VOQ Audit, Initiate Grant 
Audit 
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Flush. The VOQ identifier indicates 
which VOQ count should be cleared. * 


1 


1 


Terminate Grant Audit ** 



* The flush audit type is filtered at the GRX TX MAC. 
** The grant audit code is filtered at the GAP ASIC 



VOQ4-0 VOQ identifier bits. When the valid bit is active, this field indicates which line 

unit VOQ is granted access to the upstream GigaPoint. 
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Wordl 



Bits 31-30 Facility ID extension field. For future use, this field extends the GigaPoint facility ID to 

accommodate up to 64 ports. 

Bits 29-26 Facility ID field. These bits identify the destination facility for this packet at the target line unit. 

Bits 25-24 Plane ID bits. This field is reserved for future use by GRX/GAP ASICs capable of supporting 
four GigaPoint interface per line unit slot The future GRX fabric may be partitioned into four 
each 24-port switching fabric planes. This field allows future GAPs to specify which switching 
plane a packet is destined for. 

Bits 23-0 Routing map field. The routing map indicates which output port this packet is to be routed to at 

the GRX. While the GRX supports far fewer than 24 ports, the additional bits allow for future 
expansion. The routing map serves no purpose in the downstream GigaPoint path. Unicast traffic 
sets one of the routing map bits. Multicast traffic may set many, or all, bits active. Bit 0 
corresponds to GigaPoint port 0, bit 21 to port 21, etc. 
0 = Do not route to corresponding port. 
1= Route to corresponding GRX GigaPoint output port. 



Flow ID extension field. The flow identifier extension field carries routing information in addition 
to the 16-bit flow ID generated at the line unit's packet processor. Full use of the flow ID and 
flow ID extension accommodates up to 1 million flows. The GRX passes the flow ID extension 
field and does not process its contents. 

Flow ID field. This flow identifier field is used by line units within the C7 shelf to identify 
individual flows at the packet processor. The GRX passes the flow ID field and does not process 
its contents. 

Bits 11-0 Virtual port identifier bits 1 1-0. 
EP Word 3 

J~ Bits 31-16 Virtual connection identifier 15-0. 

C Bits 15-3 Payload type identifier bits 2-0. 



Word 2 

Cl Bits 31-28 



Bits 27-12 



Bit 12 Loss plan bit. 

Bits 1 1-8 Reserved for future use. 

Bits 7-0 HEC. Header error check byte for all four 32-bit words of the GigaPoint header. The HEC byte is 

derived from an x A 8+x A 2+x+l coset polynomial capable of detecting single and multi-bit errors. 
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3.5.6.2 Class of Service 

The GigaPoint bus supports transport of up to sixteen classes of service. Class of service information is transport in 
three different GigaPoint header fields. They are: 

• Packet class of service field 

• Packet arrival class of service field 

• Packet grant class of service field 

Class of service ranges in priority from the highest priority of '0000 5 to the lowest priority of ' 1 1 1 1 ' 

3.5.7 TDM Packet Format 

The format of TDM packets supported by the TSI is presented in Figure 10. Only 24 DSO channels out of 30 are 
supported in the first release of the ASIC. The header byte following the ATM header is used to carry a 6-bit frame 
sequence value and a direction bit (upstream/downstream). The last two bytes of the payload are used for a Control 
Byte and a Pad Byte. 
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GigaPoint Packet Header 



GigaPoint Packet Payload 

Figure 10 - TDM Packet Format 



3.5.7.1.1 Packet Header 



All TDM FLPs within a TSI group carry the same VPL The VCI field carries the TDM slot number. This value 
serves two purposes. It controls the packet's position within the SONET frame and it acts as an internal routing tag 
in the C7 system. 

3.5.7.1.2 TDM Header Byte 



The direction bit is set to 4 0' for downstream traffic and set to 6 1 ' for upstream traffic. The TSI can be configured to 
set this bit to 4 0' or ' 1 When used as a trunk card, the TSI must be configured to set the downstream/upstream bit 
to '0'. 

The frame sequence field is incremented every 125us frame, cycling from 0 to 47 every 6ms periods. When 
receiving packets from an external packet processor chip or the GigaPoint, the 6-bit frame sequence field is used by 
the TSI to perform frame synchronization. The frame sequence field is on a per-VC basis meaning that all VCs are 
not required to be in the same frame sequence at any given time. When transmitting packets towards the external 
packet processor chip or the GigaPoint, the TSI sets the frame sequence field to the local frame sequence counter. 
The frame sequence counter is synchronized to the GigaPoint super-frame and is unique for all VCs. 



A-23 



The parity bit is a parity calculation for the seven remaining bits of the header. Software can program the TSI for 
even or odd parity. Parity is set to even by default. 

3.5.7.13 TDM Payload 

The TDM packet data format supports up to thirty B-Channel or DSO bytes. By default, one DS1 (24 B-channel) is 
transported every frame. The expansion capacity allows future transport of El (30 B-Channel) payloads. Fifteen 
additional bytes transport four signaling bits per B-Channel. 

The Control Byte at the end of the payload is used for communication between line units and trunk cards. Refer to 
section 3.5.8 for more details. 

The pad byte is reserved for future use. 



3.5.8 Control Channel 



The Control Byte located at the end of the packet payload allows software to send messages from a trunk card to a 
line unit card located in a remote shelf and vice-versa. Care must be taken when launching control information from 
a DS1 card as the packet can merge with other packets at the GRX ASIC. 

At the receive end, the TSI latches the last non-zero value on a per-VC basis. In reason of jitter, interval between 
packets can be less than 125us at the receiver. If a packet for a given VC arrives before software has read the 
previous value, the TSI overwrites the previous value with the new one. 
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Figure 11 - Control Channel 
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4 Design Description 



This section describes the current GigaPoint interface design implementation. 



4.1 Receive Descrambler/Overhead Processor 



The receive descrambler/overhead processor depicted in Figure 12 is composed of two sub-modules: 

• The SONET descrambler restores receive data to its raw state and tests for BIP-8 errors 

• The Overhead extract sub-module latches overhead state bits from GK1 and GS1 octets 

While the descrambler decodes the mcoming data stream, it maintains a BIP-8 parity value. The parity check is 
reset on every frame and the result is latched for comparison with the GB1 overhead byte of the subsequent frame 
overhead. Detection of a parity error generates an interrupt to the processor module. The descrambled data drives 
the overhead capture module and the receive synchronous traffic processor. 
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Figure 12 - Receive Descrambler/Overhead Processor 



4.1.1 SONET Descrambler 



The SONET descrambler is based on the scramble mask generator depicted in Figure 13. The descramble mask 
generator is a 40-bit parallel implementation of this generator. The descrambler is preset at two points within the 
frame GA1 insertion and GA2 insertion. SONET row, column, and timeslot counters are preset by the framer. 
Strobes decoded from the counters identify the 40-bit words that carry GA1 and GA2 overhead bytes. GA1 and 
GA2 are in the MSB of their 40-bit words. During the GA1 and GA2 word slots, specific segments of the 
scramble/descramble sequence are preset into a 40-bit parallel scramble mask generator. When GA1 and GA2 are 
inserted, a byte-wide multiplexer bypasses the scramble mask. Only GA1 and GA2 in the overhead channel mask 
bypass the scramble/descramble process. 
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4.1.2 Scrambler Sequence 
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Figure 13 - Scramble Mask Generator 



A frame synchronous scrambler of sequence length 127, operating at the line rate, is used. The generating 
polynomial is l+x 6 +x 7 as shown in Figure 13. An exclusive OR operation is performed on the GigaPoint frame with 
the repeated 127 bit sequence. This sequence, generated by the pseudo random number generator (with the 
generating polynomial, l+x 6 +x 7 ), is obtained by dividing binary 11 111 11 by 10000011. The 127-bit sequence is 
shown in 40-bit groups below; 

FE 04 18 51 E4 

11111110 00000100 00011000 01010001 11100100 

59 D4 FA 1C 49 

01011001 11010100 11111010 00011100 01001001 

B5 BD 8D 2E E6 

10110101 10111101 10001101 00101110 11100110 

2A (7 bit) 
0101010 

The same operation is used for descrambling. For example, the input data is 000000000001 111111111. 



00000000 00001111 11111111 <- 
11111110 00000100 00011000 <- 
<- 



input data from crosspoints 
scramble sequence at TX MAC 
exclusive OR (scramble operation) 



11111110 00001011 11100111 < - scrambled data over GigaPoint 



11111110 00000100 oooiiooo <- 
<- 



descramble sequence at RX MAC 
exclusive OR (descramble operation) 



00000000 00001111 11111111 <-- output data to GAP 
4.1.3 Overhead Extract 



The overhead extract module makes use of the descrambler's column, row and slot counters to identify the position 
of overhead bytes GK1 and GS1. These bytes are latched on the decoded strobes. The decoded GK1 and GS1 bit 
fields are driven to the appropriate registers within the GP MAC's processor interface. The five-bit frame count 
field from GK1 is compared to the core frame counter. If there is a mis-match ? an error is reported to the MAC 
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processor interface. The GigaPoint channel configuration bit (mac_rx_config) is driven to the synchronous 
crosspoint. In the GAP, active, protect, and line unit reset are decoded from GS1 and driven to the GAP core logic. 
The 5-bit state word field is written to GP MAC registers. A change in the value of the state word generates an 
interrupt to the local processor. 

Line unit reset is qualified by the following conditions: 

• The GigaPoint MAC must have active = 1 and protect = 0 

• The reset condition must be constant for one full superframe 

• No receive GigaPoint errors during that superframe 



4.1.4 GigaPoint Payload Descrambler 



The GigaPoint payload descrambler is implemented in a manner similar to that of the SONET descrambler. A 
polynomial is generated from a preset state on a superframe interval. The resulting scrambler mask words are 
XORed with GigaPoint data at the scrambler and descrambler blocks. The payload scrambler differ from the 
SONET scrambler in the following ways: 

• The payload scrambler polynomial is generated on the 6ms superframe rather than the 125us frame 

• The payload scrambler polynomial is different 

• The preset word at superframe sync is configurable from software 

At superframe sync, the 48-bit seed word from the Payload Scrambler Seed register is loaded into the scrambler 
register. On each following 77.76MHz clocks, the scrambler register contents are fed back to the input through a 
40-bit offset XOR equation that provides the next 40-bit value in the polynomial 

The resulting 40-bit word is XORed with the receive GigaPoint data immediately after the overhead extract stage of 
the descr oh block. The descrambled GigaPoint receive payload/overhead is driven to the receive frame align 
FIFO. 
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4.2 Transmit Scrambler/Overhead Processor 

The transmit scrambler/overhead processor is depicted in Figure 14. The transmit scrambler/overhead processor is 
composed of three functions: 

• The overhead generator sub-module inserts overhead state bits into GK1 and GS1 octets 

• The SONET scrambler scrambles raw transmit data and calculates frame BIP-8 parity 

• The Payload Scrambler scrambles raw transmit data based on a software-provisioned seed value 
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Figure 14 - Transmit Scrambler/Overhead Processor 

The transmit SONET scrambler, overhead generator, and payload scrambler functions are described in greater detail 
in the receive scrambler/overhead processor block in section 4.1 above. 



4.2.1 Overhead Generator 



The overhead generator block latches state bits from the GAP processor interface's registers and the channel config 
page bit from the sync crosspoint These state bits are inserted into the overhead channel's GK1 and GS1 octets 
once each frame. As with overhead capture, the overhead insertion function makes use of the column, row and slot 
counters used in the SONET scrambler function. 



4.2.2 SONET Scrambler 



The SONET scrambler encodes transmit data, with the exception of the overhead channel's GA1/GA2 framing 
bytes, using the standard 127-bit sequence algorithm. The generating polynomial is l+x 6 +x 7 . The scrambler 
function makes use of transmit SONET column, row and slot counters. While the scrambler encodes the transmit 
data stream, it calculates a frame BIP-8 parity value. The parity check is reset on every frame and the result is 
latched and inserted into the overhead byte GBL The scrambled 40-bit data is driven to the transmit SerDes 
interface sub-module. The scrambler algorithm is described in detail in 4.1 .2. 
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The scrambler block's counters generate an end-of-superframe signal for the async packet processor. For a given 
async channel count, the async counter must ensure that a read does not occur in an async/sync packet slot that will 
not complete before the end of superframe. This area at the end of superframe does not transport packet traffic. An 
async channel counter is incremented by the number of async channels in the GigaPoint channel map words. This 
count runs once every superframe on the first 12 clocks after sf_sync. The resulting count is applied to a look-up to 
determine the frame count value for the last valid async packet slot. The value is compared to the superframe 
counter to disable output FIFO reads during this time period. 
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4.3 GigaPoint Header Generation 



The 64-byte GigaPoint packet, or fixed-length packet (FLP), consists of a 16-byte header and 48-byte payload. In 
order to interface to 3 rd party physical interfaces (PHYs) and packet processors, the line unit GAP ASIC supports the 
ATM UTOPIA interface. Figure 15 shows ATM headers (without HEC} as they are transported within the GAP 
ASIC. The GAP ASIC prepends additional header fields extending the first four bytes of the ATM header to 16 
bytes as illustrated in Figure 16. The GigaPoint header fields are used through the C7 system to identify and route 
the packet Definitions of the fields can be found in the GigaPoint Bus Hardware Architectural Specification. 

Note that both Figure 15 and Figure 16 represented header in 32-bit format. Packet data is transported in 64-bit 
word. 
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Figure 15 - ATM Header at UTOPIA Interface 



Bit > 


3 1 3 1 2 1 2 
1 1 0 1 9 1 8 


2 I 2 I 2 I 2 
7 | 6 I 5 | 4 


2 I 2 | 2 I 2 I 1 I 1 
3l2|1 | 0 | 9 | 8 


1 I 1 1 1 

7 I 6 I 5 


1 

4 


1 
3 


1 
2 


\ | I | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 


Word 
0 

[63 32] 


Packet 
Type 
[3:0] 


Packet 
COS 
[3:0] 


Packet 
Length 
[5:0] 


Content 
extension 


A 
L 
O 
O 
P 


B 
P 


G 
B 
P 


Up: Packet Arrival 
Down: Packet Grant 
[11:0] 


Word 
0 

[31-0] 


Facs% 
ID Ext 


Facility 
ID 

[3.0] 


Plane 
ID 

[1-0] 


Routing Map 
[23:0] 


Word 
1 

[63 32] 


Row ID 
Extension 
[19:18] 


Flow ID 
[15:0] 


VPI 
[11:0] 


Word 
1 

[310] 


VCl 
[15:0] 


PTI 

[2:0] 


C 
L 
P 


rfu 

[3:0] 


HEC (of 120 bits) 
[7:0] 



Figure 16 - GigaPoint Header 

The GAP ASIC stores the first four bytes of the ATM header. The ATM HEC byte is checked at the GAP's 
UTOPIA interface, but not transported to the GigaPoint header generation logic. A GigaPoint HEC is calculated 
over the first fifteen bytes of the header. The additional header information is inserted from software-configurable 
registers within the GAP UTOPIA interface. GigaPoint header word 0 bits 14 through 0 and the GigaPoint HEC are 
inserted at the GAP GigaPoint interface. 
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Figure 17 details GigaPoint header generation. Input data is received from the UTOPIA ingress FIFO in 64-bit 
words. The GigaPoint header is transported in two consecutive 64-bit words. At start of packet, a 64-bit "pad" 
word is registered at the data_pipe register. 

On the second clock, the first four bytes of the received ATM header are registered into bits 31:0 of the datajpipe 
register. During this clock cycle, data_pipe[63:32] are not updated. The hdr_storage register contains software- 
configured fields, ready for insertion into the data stream. 

On the third clock cycle, the datasop signal is high, This commands the data_int_max and datajnux to select the 
GigaPoint header fields from hdr_storage. The 32-bit ATM header is also driven from data_pipe2 through 
datajbxtmux. The 64-bit multiplexer outputs are register in the dataint and data registers. At this time, the data 
register holds the first 64-bit GigaPoint header word and the data int register holds the second word. The first two 
64-bit words of packet payload are registered at data_pipe2 and data_pipe. 

For the remaining six clock cycles, data__sop remains low and 64-bit data words are transferred from the ingress 
FIFO, through datajipe, data_pipe2, datajnt and data registers to GAP core logic. 

After GAP processing, the 64-bit data is driven to the GAP GigaPoint (GP) egress interface. At the GP interface, 
the first packet word arrives coincident with tdatsop. tdat_sop id high during the first data word. tdat_sop selects 
GigaPoint header data bits 46 through 32 from the GAP core logic. The resulting 64-bit word is stored in the 
sync_tdat register and driven as output data. 
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